In a denial-of-service (DoS) attack, a malicious client (called the attacker) performs operations designed to partially or completely prevent legitimate clients from communicating with or gaining service from a server (called the victim). DoS attacks are common and cause significant losses. Well-known sites, including Amazon, buy.com, E*Trade, eBay, Yahoo, CNN, the White House and the Pentagon are among recent victims. DoS attacks can harm sites in two ways. First, when a site cannot serve its clients, the site loses advertising and sales revenues. Second, the site's clients, advertisers, and investors are frustrated and may therefore seek competing alternatives.
Among DoS attacks, congestive ones are the most difficult to defend against. In a congestive attack, an attacker floods a server with so many packets that the server is unable to respond to requests sent by legitimate clients. Four factors make it difficult to defend against congestive attacks. First, any host connected to the Internet can be used to sustain a congestive attack against any victim also connected to the Internet. By design, the Internet will forward packets from any host to any other host on a best-effort basis, without bounding packet rate or volume. Second, there are many hosts (e.g., in homes and universities) that are connected to the Internet and do not have the benefit of proper system administration. Such hosts often contain bugs or are configured in such a way that attackers can, without authorization, use them as agents, i.e., as hosts that actually send attack packets to a victim. Agents provide cloaking and leverage to an attacker, i.e., respectively, hide the attacker's identity and multiply the attacker's resources (e.g., bandwidth). Third, attackers can spoof attack packets, i.e., falsify the packets' source addresses. Spoofing is possible because the Internet does not validate source addresses. Spoofing further enhances an attacker's cloaking. Finally, automated tools of increasing sophistication for mounting DoS attacks can be easily downloaded from the Web. Using such tools, even unskilled Web users can mount successful attacks.
The two currently most popular DoS attack techniques, smurf and TCP SYN flooding, are both congestive. In a smurf attack, the attacker sends ICMP echo requests to a network's broadcast address. The attacker spoofs the requests with the victim's address. Therefore, each host in the network sends a reply not to the attacker but to the victim, thus unwittingly becoming an agent of the attack. In a TCP SYN flooding attack, the attacker or its agents sends TCP SYN (i.e., connection request) packets to the victim, usually with a spoofed source address. Each such bogus request causes the victim to tie up resources that could be otherwise be used for requests from legitimate clients.
The origin of a congestive DoS attack that uses spoofing can be found by input logging (see, e.g., “Characterizing and Tracing Packet Floods Using Cisco Routers,” Cisco, available at http://www.cisco.com/warp/public/707/22.html). To use input logging, the victim must initially determine the signature of the attack, i.e., how the attack packets differ from legitimate packets. ISP personnel then install a filter matching the attack's signature in the egress port of the router closest to the victim. The filter generates a log that indicates from what ingress port the attack is coming. Input logging is then iterated for the next upstream router, until the router closest to the origin of the attack is found. A rate-limiting filter matching the attack's signature is then installed in the ingress port from where the attacking is coming.
Input logging has several limitations. First, input logging may not be available or may prohibitively slow down routers, especially in the network core. Second, traceback using input logging may need to stop far away from the attack origins (e.g., because of administrative boundaries), where it many not be possible to distinguish malicious and legitimate packets (e.g., TCP SYN packets) that arrive in the same ingress port. Thus, input logging may be ineffective if the attack is evenly distributed among ingress ports. Finally, input logging is often a labor-intensive, tedious procedure performed under pressure and usually without adequate compensation to the ISP.
To prevent smurf attacks, the Internet Engineering Task Force (IETF) has changed the default treatment of directed broadcast packets by routers. Instead of accepting and forwarding directed broadcast packets, routers should now by default drop them. Additionally, to thwart spoofing, the IETF has recommended ingress filtering (see, e.g., P. Ferguson and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing,” IETF, RFC 2827 (also BCP 0038), May 2000). With ingress filtering, ISP ingress routers will drop a packet that arrives in a port if the packet's source address does not match a prefix associated with the port. Ingress filtering automatically stops attacks that require spoofing. Moreover, if an attack that does not use spoofing occurs, ingress filtering allows the origin of the attack to be determined simply by examining the source addresses of attack packets. Therefore, ingress filtering can speed up recovery from such attacks. Disadvantageously, to be effective, the IETF's recommendations need to be adopted by many parties (the networks unwittingly used in smurf attacks and all ISPs) that are thereby burdened with new responsibilities and costs, but receive no compensation for solving the problem of other parties (the victims). Furthermore, if ingress filtering is not uniformly adopted across the Internet by all ISPs, the source address of a packet cannot be trusted to be the actual origin of that packet, thereby making spoofing still an effective tool for launching DoS attacks. Therefore, adoption of ingress filtering has not been widespread.
IP traceback has been proposed as an alternative to ingress filtering (see, e.g., S. Savage, D. Wetherall, A. Karlin and T. Anderson, “Practical Network Support for IP Traceback,” Proc. SIGCOMM'2000, pp. 295-306, ACM, Stockholm, Sweden, August 2000). Unlike ingress filtering, IP traceback can be effective even if not widely deployed. IP traceback modifies routers so that they probabilistically send traceback information to a packet's destination. Statistical methods allow a victim to use such information to partly reconstruct the attack path (the reconstructed part is that closest to the victim). However, IP traceback has weaknesses that may affect the likelihood of it being adopted. In particular, traceback information sent by routers that are further from the victim than is the closest attacker can be spoofed and therefore needs authentication. The infrastructure necessary for such authentication may add considerable complexity and vulnerabilities of its own. Moreover, IP traceback may increase ISP responsibilities and costs without contributing to ISP revenues.
If universally adopted, ingress filtering, noted above as being recommended by the IETF, would protect against spoofing, such that the source address in each packet can be trusted to reveal the packet's origin. Since, however, ingress filtering in the near future is only going to be incrementally deployed in the network putting the trustworthiness of the source address of every packet in jeopardy, a methodology is needed that can take advantage of the protection that ingress filtering affords where it is provided, but which benefit it does afford is not negated by the fact that it has not yet been uniformly adopted by all ISPs that are connected to the Internet.